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Remarks 

Applicant respectfully requests reconsideration of the present application in view of the 
foregoing amendments and in view of the reasons that follow. 

Claims 1-14 remain pending. Applicant has amended independent claims 1 and 8 to 
change "automation device" to "end automation device". This change is clearly supported in the 
original specification: "[0028] In FIG. 1, the end device is an IO module 203, although it could 
be any number of other automation devices." Applicant respectfully submits that no new matter 
has been added by this amendment. 

This amendment was made to clarify that the "automation device" referred to in the 
claims is the "end automation device" residing on the fieldbus or I/O network 205 of Figure 1, as 
opposed to the PLC 202 that resides between the fieldbus and the Ethernet network 202 of 
Figure 1 . Although Applicant believes that this would have been clear to those skilled in the art 
before this amendment, it is important to understand that the "end automation device" referred to 
in the claims could also be a PLC, as further described in paragraph [0028] of Applicant's 
original specification, configured as an end automation device if residing solely on the fieldbus. 
"For instance, the automation device could be a programmable logic controller, an IO head, an 
inverter, a breaker, a sensor, a vision device, a bar code reader, or any other device that may be 
found in an automation environment." (Applicant's specification, paragraph 0028). 

In Paragraphs 4-8 of the Office Action, the Examiner rejected claims 1-14 under 35 
U.S.C. § 103 as being unpatentable over Blackett in view of Johnson. The Examiner stated that 
Blackett teaches encapsulating information formed in one protocol in another protocol used by 
the information receiver, and that it is a known process for overcoming the protocol difference 
(e.g., col 8, lines 34-46). However, the Examiner conceded that Blackett does not specifically 
teach the feature of encapsulating a browser request in a Modbus type protocol. The Examiner 
also stated that Johnson teaches that field devices can be embedded with a web server so as to 
communicate with an Internet browser (i.e., over an HTTP protocol), wherein the Modbus 
protocol is included as one of the fieldbus protocols, and that the encapsulation technique is 
recommended for transmitting requests written in local protocol to a remote receiver that uses a 
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different protocol (e.g., paragraphs 9, 20, and 154 of Johnson). The Examiner concluded that it 
would have been obvious to have an embedded web server in Blackett's slave devices because 
(1) embedding a web server in a field device is well known in the industrial field control, and (2) 
by doing so, it would greatly simplify the protocol processing tasks at Blackett's master device. 
Applicant respectfully traverses this rejection. 

Blackett, U.S. Patent No. 6,792,337, describes a power management architecture for an 
electrical power distribution system including master intelligent electronic devices having the 
capability to monitor and control attached slave devices, and provide capability to communicate 
between multiple devices in a variety of communications protocols. The master devices have 
web server capabilities to permit the user to view data over an open Internet protocol, such as 
HTTP. Master protocols include Modbus protocols and ION protocols. Figure 7 of Blackett 
illustrates a master device 700 coupled to a first network 725 using the Modbus protocol and a 
second network 730 using the ION protocol, and their associated slave devices. 

The Examiner referred to Figure 7 of Blackett, and in particular, col. 8, lines 34-46 to 
describe Blackett's teaching of encapsulating the request message. The relevant portion of this 
passage states "It will be appreciated by one skilled in the art that a master protocol can be 
transmitted over TCP/IP by wrapping/encapsulating it in the appropriate manner, however a 
master protocol master can also communicate directly over a particular media without using 
TCP/IP." This is the only place in Blackett that uses the words "encapsulate" or "wrap". 
Moreover, Applicant cannot find where Blackett actually teaches how a master protocol is 
actually encapsulated into another protocol for transmission over TCP/IP. It appears that 
Blackett only suggests that encapsulation is known in the art. 

Furthermore, column 16, lines 64 et seq. of Blackett state "As described earlier the device 
circuitry converts and processes the data or commands from the proprietary protocol such as the 
Modbus protocol or the ION protocol, to a third common Internet network open protocol, such as 
HTTP." This protocol conversion technique is mentioned several times throughout the Blackett 
reference. Protocol conversion appears to be the primary mechanism for gathering data from 
slave devices in Blackett. 
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Nowhere does Blackett suggest any need for a web server in any slave device, contrary to 
that suggested by the Examiner. Instead, its master devices have a web server, and protocol 
conversion appears to be the mechanism to communicate with the slave devices on a fieldbus. 
Furthermore, Blackett's Figure 9 suggests a different solution to simplifying the protocol 
processing tasks of the master devices: "[0081] It will also be appreciated that a slave device can 
also contain master device functionality. A device with master/slave functionality, as shown in 
FIG. 9, utilizes master functionality to aggregate and process data within sub-networks. . . . The 
master device 600 [sic (900)] is configured to poll the data from only the master/slave devices 
905, 955, thereby reducing the amount of connections and processing power that is required by 
the master device 900." Figure 9 does not suggest embedding a web server in the end devices. 

Johnson, U.S. Patent Application No. US 2004/0254648A1, describes a process control 
system using networked field and control devices that provide a virtual machine environment. 
Figure 1 of Johnson shows control devices "coupled, via one or more networks 48 that are, 
preferably, IP -based such as, by way non-limiting example, Ethernets." (Johnson, paragraph 40). 
Figure 2 of Johnson, however, shows a more particular embodiment wherein one or more field 
devices 62 and 64 are coupled to one or more networks 66 and 68. "Native controller 60 
(corresponding, for example, to controller 36) executes control algorithms to control associated 
non-native field devices 64, e.g., via any variety of commercial and/or proprietary field bus 70 
hardware and protocols." (Johnson, paragraph 46). Furthermore, native field device 62 is a 
sensor, actuator, or other field device. (Johnson, paragraph 47). 

Figure 2 of Johnson shows that "Java Enabled Field Device" 62 includes a web server. 
Hence, the Examiner is correct in that Johnson teaches that a web server can be embedded within 
a field device so as to communicate with an Internet browser. However, two important points 
need to be noted. First, Johnson only teaches that a field device connected to the IP -based 
network has a web server. Specifically, only field device 62 in Figure 2 shows that a web server 
is included. To the contrary, field device 64, connected to the fieldbus 70, is not shown to 
include a web server. Instead, its controller 60, connected to the IP -based network 68, is shown 
in Figure 2 to have a web server. This is consistent with the teaching of Johnson. Second, there 
is no teaching in Johnson of communicating directly between the web browser and field device 
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64 of Figure 2 over the fieldbus 70. Instead, Johnson states "... the controller 60 utilizes a 
embedded operating system that supports web serving and the JVM." (Johnson, paragraph 
0046). This is also consistent with the teaching of Johnson, as HTTP messages are not being 
encapsulated into Modbus messages. 

The Examiner recited paragraph 154 of Johnson as an example of the Johnson Modbus- 
into-HTTP encapsulation technique. Applicant has fully considered the teaching of Johnson, and 
particular this paragraph 154 and the others mentioning the word '"encapsulating", but cannot 
understand how this purported encapsulation works. It is not described in sufficient detail in the 
Johnson description. Applicant respectfully submits that this passage is not enabling and 
therefore not a proper basis of rejection. If the Examiner maintains this basis of rejection, 
Applicant requests a more detailed explanation and a fair chance to respond. 

In sum, any combined teachings of Blackett and Johnson cannot render obvious 
Applicant's claims for at least the following reasons: 

(1) Any such proposed combination still lacks the claimed elements of (a) 
sending a request message from said web browser to a process that encapsulates said 
request message in a Modbus type protocol; (b) transmitting said request message to said 
end automation device; and (c) responding to said request message by the automation 
device with a reply message using the Modbus type protocol. Neither reference even 
suggests a need for encapsulating web browser request messages into Modbus type 
messages. 

(2) Blackett and Johnson both suggest encapsulating a fieldbus protocol message, 
such as a Modbus message, into an IP -based protocol message, such as an HTTP 
message. This is essentially the opposite of Applicant's invention, e.g., of encapsulating 
an HTTP message within a Modbus message. This teaching away would not lead one 
skilled in the art to combine the Blackett and Johnson references (particularly with those 
standard IP -based network configurations) to combine these references to solve the 
problems described by Applicant (while knowing that the Modbus protocol is widely 
used in factory automation applications). 
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(3) Any such proposed combination of Blackett and Johnson would not work in 
Applicant's legacy Modbus-type system topologies and applications currently deployed in 
the field, without major upgrades to Ethernet-based topologies, which would be cost and 
time prohibitive in most circumstances. Applicant's claimed invention is directed to 
solving this problem. 

Applicant's dependent claims include all the limitations of their respective independent 
claims, and thus the same reasons would apply regarding Blackett and Johnson. Therefore, 
Applicant respectfully submits that the dependent claims are also patentable over the references 
of record. 

In light of the foregoing Amendments and Remarks, Applicant respectfully submits that 
all claims are now in condition for allowance. Favorable consideration of the application as 
amended is respectfully requested. 

The Examiner is invited to contact the undersigned by telephone if it is felt that a 
telephone interview would advance the prosecution of the present application. 



Respectfully submitted, 



Date 



January 21. 2009 



By 



/Douglas A. Boehm/ 



Schneider Electric USA 
1415 S. RoselleRoad 
Palatine, Illinois 60067 
Telephone: (847)925-3459 



Douglas A. Boehm 
Attorney for Applicant 
Registration No. 32,014 
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